Subject: FSM documentation strategy

From: [email-masked]
Date: Thu, 7 Apr 94 10:33:40 EDT

Steve,
Since your latest 6611 FSMs generally contain additions to make the
RFC1434 FSMs complete and workable (e.g., HALT_DL_NOACK), I think
they are a reasonable starting point for our continued RIG discussions.
However, they do describe 6611 operation and will need modifications
if they are to become the DLSw standard.  I propose that you leave the
file /aiw/dlsw/connect/fsm-6611-01.txt as you have placed it on
ibmstandards (for reference by anyone seeking to understand the 6611
or interoperate with it), and make a copy of that file which this RIGlet
can then modify and later approve as the "standard" DLSw FSMs.  Maybe
you could name it 'fsm-draft-01.txt' and increment the version number
whenever you incorporate some changes.

At first glance, here are some changes that should be considered for
the draft FSMs but not for the 6611 FSMs:
  - With the RIG's consensus on adaptive flow control, it is no longer
    correct for the FSMs to include ENTER_BUSY and EXIT_BUSY as events
    with actions that require RNRing/RRing end stations.  I would
    remove them from the FSMs, and maybe move their rows from the
    SSP Message Types list into a new section for "Retired Message
    Types".  (I think there's value in having the standard at least
    list the old values for reference).
  - As you mention, maybe "failure of TCP connection" should be
    genericized.  I'd prefer "Transport connection failure".
  - There was recently an exchange on the mailing list about
    non-activation XID support.  If everyone agrees, we should add
    XID events to the CONNECTED state.
  - We have work to do to incorporate the explorer vs. circuit setup
    concepts into the FSMs.
  - I think there are some other places where we want to specify
    different implementation options.

As far as changing the terminology, I would support including some SDLC
language in the "Descriptions" part of the "DLC Events" and "DLC Actions"
sections of the new file.  I would have a big problem with any proposal
to rename events or actions, because I think we have much more important
work to be doing.

I feel it's time to get serious about getting this stuff to the point
where we feel good advancing it along on the standards track.  Moving
the FSMs into a separate file that can be the clear object of our
discussion and on which we can take a position about standards advance-
ment is key, in my opinion.  Maybe we can do AD status via e-mail on
the discrete riglet deliverables, then go for AP status on the collect-
ion of them which Alan will produce.

Peter Gayek
IBM Corp.

---

From: Gnanaprakasam Pandian <[email-masked]>
Date: Thu, 7 Apr 94 9:59:53 PDT

Steve,
While you are at it please consider the following.
Some of them are to enhance the robustness of the current state machine. 
Assuming DLSW is going to be widely deployed
on a wide variety of devices having limited capabilities, 
despite the fact that it rides on top of
a "reliable" transport we need to be conservative in the design of the
state machine. 
	- Negative acknowledgements to speed up the 
	  convergence if one chooses to implement SSP message retries.
		CUR - I CAN'T REACH
		CONTACT - COULDN'T CONTACT
		May be ... "I am trying to reach " type of a message
		for an impatient remote side which keeps sending
		retries. 
	  I am not thinking about other SSP message types right now.
	- Session level keepalives - during CONTACTED state.
	  ( Could be overloaded later on for using as IPMs)
	- RIF type (ARE/SRE.. bit) in the SSP - CUR
	- LF(MTU) field in the SSP - CUR
	- for NETBIOS - NAME_IN_CONFLICT and STATUS_QUERY treatement
	- Uniform structure for remote/origin/target ckt ids in the SSP.
	  Right now remote ckt id fields are swapped.
	- Did we cover all the collision cases for frames
	  crossiing each other.
thanks
	/pandian - cisco eng.

-- 
G. Pandian           + Gnanaprakasam Pandian      +
Cisco Systems, Inc.  + Software Engineer          +           
1525 O'Brien Drive   + Phone : (415)688-7684      +
Menlo Park,          + FAX   : (415)688-8282      +
CA 94026             + E-mail: [email-masked] +